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Descriptron 

5 Field of the invention 

This invention relates to communication between a private network and a 
roaming mobile terminal. 

Backarounri r>f the inventi«^ i ^ 

Many organisations utilise private networks, whose communications with 
tem^inals outside the private network pass th«,ugh security gateways that protect 
the private networic using techniques including firewalls. 

Protection of private corporate Information Is of utmost Importance when 
designing an lnfom,a«on Infrastructure. However, the separate private networking 
solutions are expensive and cannot be updated quickly to adapt to changes in 
business requirements. The Internet, on the other hand, is inexpensive but does 
not by itself ensure privacy. Virtual private networking is the collection of 
technologies applied to a public networi. - in particular the Internet - to provide 
solutions for private networking needs. Virtual private networks use obfuscation 
through secure tunnels, rather than physical separation, to keep communications 
dxj private. 

Virtual Private networks (VPN') accordingly enable private networks to be 
extended to enable securitised communication with roaming temiinals. that Is to 
say terminals situated outside the private networic. the communication passing for 
example through the Internet and possibly over mobile telephone network. The 
25 Internet uses Internet Protocol ('IP) and the communications of mobile temiinals 
often use Mobile Internet Protocol ('MIP*). 

It Is expected that tiie roaming usage of virtual private networics will become 
bigger and more frequent. Such frequently roaming users will need to be given the 
same level of security as fixed or occasional roaming terminals, through the 
30 corporate VPN / firewall architecture. 
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Different communication and security protocols are used for the different 
networlcs. An example of Internet security protocol is the IPsec specification [S, 
Kent, R. Atkinson, "Security Architecture for the Internet Protocol", Intemet 
Engineering Task Force (IETF), RFC 2401, November 1998]. Examples of mobile 
5 telephone communication protocols are the Mobile IPv4 specification [C. Perkins, 
"IP Mobility Support", RFC 2002, October 1996] and the Mobile IPv6 specification. 
When the VPN protocol is IPsec Encapsulating Security Payload and the mobilty 
protocol is Mobile IP, both of them being implemented in the same -IP- layer, there 
is a need to specify how these two protocols must interact with each other when 
10 being simultaneously required. 

Beyond basic application order (either apply Mobile IP first, or apply IPsec 
first), the overall solution must aim at meeting three major requirements: 

• Securify. The fact that VPN infrastructure can support Mobile-IP users must 
not create new security flaws to any corporate entity (corporate network & 

15 mobile or occasionally roaming users). Mobile IP enabled devices must 

provide mobile users with the same level of security as if they were 
physically located within the corporate networic. On the other hand, Mobile 
IP entities must be adequately protected by corporate security Infrastructure 
(Firewalls) and Mobile IP specific security mechanism must not interfere 

20 with global security mechanism. 

• Compatibility. A solution that enables optimised interaction between Mobile 
IP and IPsec must avoW heavily modifying protocol specifications. Future 
evolutions of Mobile IP & IPsec protocols must not be made excessively 
difficult due to the use of an optimised combined solution. Optimally, such 

25 evolutions should be transparent to the use of the combined solution. 

• Perfomrtance. The invention must address specific needs of mobile users in 
terms of handover quality: the handover must be made as quick as 
possible. 

One example of a communication protocol for a virtual private network is the 
30 ESP (Encapsulating Security Payload) protocol (8. Kent, R. Atkinson, "IP 
Encapsulating Security Payload", Internet Engineering Task Force (IETF), RFC 
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2406. November 1998). used in tunnel mode. The most significant points are the 
folioviring: 

• The whole incoming IP packet Is tunnelled into a new one; inner (original) 
source and destination addresses are not changed. 

• The whole incoming IP packet is encrypted and optionally (recommended) 
authenticated. 

ESP tunnel mode is by definition a unidirectional peer-to-peer protocol. The 
sender (the one that encrypts and tunnels) and the receiver (the one that 
detunnels and decrypts) must share a cryptographic secret (e.g. key and algorithm 
used for encryption/decryption). The set of security parameters (protocol, key, 
algorithm, sender address, receiver address, lifetime, ...) constitutes a so-called 
IPsec Security Association {'SA% IPsec requires two SAs (an SA bundle) to obtain 
a secured unidlrecttonal communication: one on the. sender and one on the 
receiver (with some common parameters, ibr example the key). 

As a VPN communication is bidirectional (from Mobile Node ('MN') to VPN 
Gateway and from VPN Gateway to MN), two SA bundles are required: the first 
one descn-bes the tunnel from MN to VPN Gateway, the second one describes the 
tunnel from VPN Gateway to MN. It must be noted that the designation 'VPN 
Gateway" is not specified by the protocol: a VPN Gateway is simply the topologic 
20 entity that temilnates, at the corporate network side, all VPN secure tunnels 
to/from roaming mobile nodes. 

SA selectors are used for the processing of IPsec packets. Basically. SA 
selectors are IP parameters that are used by IPsec layer to check that 

• A packet that is about to be sent on a tunnel defined by a certain outbound 
SA is actually legitimate to be sent with that SA (e.g. source & destination 
addresses of the packet match with source and destination address of the 
SA). This test is called the "outbound SA selector check". 
. A packet that has been received from a tunnel defined by a certain Inbound 
SA is actually legitimate to have been received with this SA (e.g. source & 
destination addresses of the packet match with source and destination 
address of the SA). This test is called the "inbound SA selector check". 
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It must be noted that, as illustrated in the two examples above, only source 
address & destination address will be considered in this invention as SA selectors 
for both inbound and outbound SAs. 

Two families of proposals address this situation: 
/Psec tunnol in the M!P tunnel. 

With this family of proposals, the IPsec tunnel Is established between the 
VPN Gateway and the Mobile Node Home Address. 

External home agent. The home agent is placed in front of the IPsec gateway 
and the corporate firewall, l.e. outside the home networic Obviously, there are 
deep security flaws; the main one is that the home agent is no longer protected by 
the common protection (corporate firewall) mechanism at the boRJer of the 
network. Indeed, a home agent placed outside the gateway does not benefit from 
any protection and become an easy target. This kind of security flaw could not be 
accepted when designing a VPN solution aimed at securing communications. 

Another problem stems from the tunnelling mechanism that does not cipher 
the MIP packets (the IPsec tunnel is inside the iVIlP tunnel). The MIP header is in 
plain text and any attacker with bad intentions will have knowledge of all header 
fields, for Instance the home address of the mobile node. Thus, this solution does 
not provide privacy and a malicious node might track all successive locations of a 
mobile node, identified through its home address. 

MIP proxy. This proposal is described in a draft (F. AdrangI, P. Iyer. "Mobile 
IPv4 Traversal across VPN or NAT & VPN Gateway", IETF work in progress draft- 
adrangi-mobileip-natvpn-traversal-01.txt, February 2002). It assumes the creation 
of a new entity called a Mobile IP Proxy that appears as a surrogate home agent 
from a mobile node point of view and conversely is viewed as a mobile node by 
the home agent. This solution is also based on IPsec in MIP tunnelling, which is 
less confidential in terms of privacy than MIP in IPsec as stated above. 

The process of simple roaming requires new signalling messages between 
the MIP proxy, the VPN gateway, and the home agent: the MIP proxy acts as a 
relay between the mobile node and the home agent ('HA'); it must be aware of 
existing protection between the mobile node and the HA to forward valid request 
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uniquely. It also interacts with the VPN gateway and a common packet from a 
correspondent node to a MN follows a heavy process: it is first MlP-encapsuIated 
by the HA to the MIP proxy. Then the MIP proxy decapsulates It and gives It to the 
VPN gateway in order to realize encryption. The VPN gateway sends back the 
ciphered packets to the MIP proxy, which encapsulates It again in a new MIP 
packet. 

The MIP proxy is located outside the protected domain in the Demilitarized 
Zone COMZ*), that is to say a small networic inserted as a "neutral zone" between 
a company's private networic and the outside public network. The security level of 
machines within the DMZ is fer inferior to the corporate networic. The firewalls 
must not interfere with the registration procedure between the proxy and the Home 
Agent. This architecture impHes possible security flaws since the corporate firewall 
must let any packets between the MIP proxy and the Home Agent go through 
without farther inspections: this can easily lead to compromise the entire corporate 
networic If an attacker can mainage to gain access to the MIP proxy. 
MIP tunnel in the IPsec tunnel 

With this family of proposals, an IPsec tunnel is established between the 
VPN Gateway and the Mobile Node Care-ofAddtvss. 

One proposal that includes the MIP tunnel In the IPsec tunnel has been 
20 described by the University of Bem. Switzerland at 
www.lam.unibe.ch/~rvs/publications/secmip_gl.pdf. The IPsec tunnel is reset 
before any new handover. When moving to a new network, it has to be re- 
established through the whole key distribution process. That handover mode 
creates unacceptable latencies of many seconds. Incompatible with classical MIP 
25 requiremente. 

Another issue with this proposal consists in assuming that IPsec offers a 
suffident protection and. as a consequence, in disabling authentication and replay 
protecBons during the MIP registration procedure. Disabling protections on the 
Home Agent is an option that does not really improve speed and requires home 
30 agents dedicated to MIP-VPN users, as well as other home agents dedicated to 
simple MIP users that still use MIP protections. 
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The present invention addresses the above and other problems. 
Summary of the inventinp 

The present Invention provides a method of and apparatus for 
communication as described in the accompanying claims. 

Brief description of the drawing s 

Figure 1 is a schematic diagram of a mobile virtual private network scenario. 

Figure 2 is a diagram of a data packet encapsulated In ESP tunnel mode. 

Figure 3 is a flow chart of exchanges In communication between a private 
network and a roaming mobile tenninal in accordance with one embodiment of the 
invention, given byway of example, and 

Figure 4 Is a flow chart of a process for reception of a registration request in 
the communication process illustrated in Figure 3. 

Detailed description of the oreferrgd embodimentR 

Figure 1 shows a mobile virtual private network scenario comprising a private 
networic 1 Including a security gateway comprising a VPN gateway 2 and a firewall 
3. a mobile node 4 situated In the private network 1 and a home agent 5 for the 
mobile node 4. The embodiment of the present Invention shown in the drawings is 
applicable especially where the mobile node 4 is capable of communication over a 
wireless link, which improves Its ability to roam, both within and outside the private 
networic 1 but this embodiment of the invention is also applicable where the mobile 
node 4 communicates only over wire connections. 

Figure 1 shows a scenario where the advantages of this embodiment of the 
invention are particularly appreciable, where the mobile node 4 moves outside the 
private network 1. first to a visited network 6 having a foreign agent 7 functioning 
under mobile IPV4 protocol, enabling communication of the roaming mobile node 
4 In the network 6 through the Internet 8 with the private network 1. in this scenario 
the roaming mobile node 4 then moves to a second visited network 9, having a 
foreign agent 10, also functioning under mobile IPV4 for communication through 
the internet 8 with the private networic 1. While this embodiment of the invention 



CMLOOeSBB* spoo EPC V/inal 



26Manh2003 



functions with Mobile IPv4 protocols, it will be appreciated that the invention is also 
applicable to other protocols, especially the Mobile IPv6 protocol. 

\Nhen the mobile node 4 is roaming In the visited networks 6 or 9, 
communications with the private network 1 are established through the internet 8 
in IPsec and MIP tunnels 11 and 12 respectively. More specifically, the protocol 
used Is the encapsulating security payload ("ESP") protocol illustiBted in Figure 2. 
According to this protocol, the original packet 13 comprises an original IP header 
14 and data 15. The packet 13 is encrypted with an ESP trailer 16 without 
changing the original IP header and destination address. The encrypted packet is 
encapsulated with an ESP header 17 and preferably an ESP authentication 18 
and assembled with a new IP header 19 before transmission. Security association 
bundles, each comprising an outbound and Inbound communication security 
association, are established for communicatfons over the paths 1 1 and 12 with the 
VPN gateway 2. Security association selectors check that packets to be sent using 
the tunnel defined by each outbound security association are legitimate to be sent 
with that security association and. In particular, that the source and destination 
addresses of the packet match with the source and destination addresses of the 
security association, this test being the outbound SA selector check. Packets 
received from a tunnel defined by the inbound security associatton are checked for 
legitimacy of reception with this security association and, in particular, that the 
source and destination addresses of the packet match the source and destination 
addresses of the security association, this test being the Inbound SA selector 
check. 

In this embodiment of the invention the inbound security association of the 
VPN gateway 2 does not contain the IP address of the mobile node 4 as source 
address but a wild card ("*")• This allows the VPN gateway 2 to receive and 
fonward a packet from the mobile node 4 whatever Care-of address it may use. It 
will be noted that this is not contradictory with IPsec protocol, since the wild card 
value is authorised by this protocol for the source address selector in a security 
association. The tunnel order Is that of an MIP tunnel in the IPsec tunnel, with the 
IPsec tunnel between the VPN gateway 2 and the mobile node 4, using the mobile 
node Care-of address as end point. 



CMUWSSeEPQiecEPC Mfoaf 



Z8Uaith200a 



The process for communications when the mobile node 4 Is roaming is 
shown In Figure 3, in which references to outbound and inbound refer to packets 
at the mobile node 4. Initially, the IPsec tunnels are Illustrated for the situation 
where communication is established at the current Care-of address of the mobile 
node 4. The outbound IPsec tunnel 20 has a security association at the mobile 
node 4. having the current mobile node Care-of address as source address and 
the address of the VPN gateway 2 as destination address, and a security 
association at the VPN gateway 2. having a wild card as the source address and 
the VPN gateway 2 address as the destination address. The initial inbound IPsec 
tunnel has a security association at the mobile node 4. with the address of the 
VPN gateway 2 as source address and the current Care-of address of the mobile 
node 4 as destination address, and a security association at the VPN gateway 2 
having the VPN gateway address as source address and the mobile node 4 Care- 
of address as destination address. 

When the mobile node moves at 22 from one visited network to another, for 
example, from the visited network 6 to the visited network 9, the mobile node 4 
recognises that Its location has changed, for example, from an incoming agent 
advertisement. It then configures a new Care-of address that Is routable within the 
new visited network 7. The mobile node 4 contains VPN client software that 
responds to the change In mobile node location, for example, in response to 
network selection middleware or by monitoring the source addresses of outbound 
packets. The VPN client software then changes dynamically the Inbound security 
association on the mobile node 4 so that Its destination address is the new Care-of 
address of the mobile node, the inbound IPsec tunnel 21 becoming a temporary 
inbound IPsec tunnel 23. In this way the mobile node 4 will be able to receive 
packets securely sent by the VPN gateway 2 to Its new Care-of address; othenvise 
the packets would be dropped as they would not match the destination address 
Included In the former inbound IPsec tunnel 21. Similarly the VPN client software 
changes dynamically the outbound security association on the mobile node 4. so 
that Its source address Is the new Care-of address of the mobile node, the 
outbound IPsec tunnel 20 becoming an outbound IPsec tunnel 20'; otherwise the 
mobile node 4 would not be able to send outgoing packets as they would not 
match the source address included in the fomier outbound IPsec tunnel 20. 
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The mobile node 4 then sends a signalling message to its home agent to 
infbmn It of its new location, the signalling message passing through the outbound 
IPsec tunnel 20* and the VPN gateway 2. This signalling message is in the fbmi of 
a registration request where the protocol used is mobile IPV4, as in this 
5 embodimentof the invention. 

The signaling message Is received at the VPN gateway 2 in step 24. The SA 
selector in the VPN gateway for the outbound tunnel 20' does not reject the packet 
since the source address is a wild card field and the source address is therefore 
not verified and the packet is forwarded to the home agent 5. At step 25 the home 

10 agent 5 receives and processes the registration request message firam the mobile 
node 4 indicating the new Care-of address. If the registration request is valid the 
home agent 5 sends a security Information update message ("SIU") to the VPN 
gateway 2 containing an order to update the security association of the temporary 
IPsec tunnel 23 on the VPN gateway. Thfe SIU message is processed at the VPN 

15 gateway 2 by a daemon, for example, that is to say a background programme that 
provides services to the system. 

In response to the SIU message the VPN gateway 2 updates its security 
association for the temporary inbound IPsec tunnel 23 to a new IPsec tunnel 26, 
having the new Care-of address of the mobile node 4 as destination address. This 
20 update is performed before any packet is sent to the mobile node 4, in particular 
the registration reply. In a preferred embodiment of the Invention the SIU message 
from the home agent 6 to the VPN gateway 2 includes the registration reply to the 
mobile node 4. 

It will be appreciated that this particular routine of the home agent 1 is 
25 triggered only when the registration request is received through a VPN gateway 
such as 2, conesponding to a location of the mobile node 4 outeide flie private 
network 1. If the mobile node were situated within the private network 1, and 
therefore not using the VPN service, the home agent 5 would respond according 
to the nomial routine with a normal registration reply. 

30 At step 27, the VPN gateway 2 fonwards the registration reply to the mobile 

node 4 using the newly-established inbound IPsec tunnel 26 and sends all further 
data packets to the new Care-of address using the tunnel 26 until further notice. 
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If at step 25 the registration request does not succeed at the home agent 5, 
the process fs not irremediably compromised. No registration reply will be received 
at the mobile node 4, which will send a further registration request. If the home 
agent 5 continues not to accept the registration requests, the mobile node 4 will 
5 ultimately abandon the attempt and establish a new tunnel for a new Care-of 
address without taking advantage of the process of this embodiment of the 
invention. This situation is inherent in mobile IP scenarios. 

Figure 4 illustrates the routines followed by the home agent 5 during the 
above process. The routine begins at 28 and at step 29 an Input is receh^ed in the 

1 0 form of a registration request from the mobile node 24. A check is made at step 30 
whether the registration request Is valid, and If the home agent 5 does not accept 
the registration, the routine terminates at 31. If the home agent 5 does accept the 
registration request, a check is made at 32 whether the registration request was 
received through a VPN gateway such as 2. If it was not, a registration reply is 

15 built and sent directly to the mobile node 4 over the private network 1 at step 33. If 
the registration request was received through a VPN gateway such as 2, a 
registration reply for the mobile node 4 is built at 34. This registration reply is then 
included In a new packet generated by the home agent 5 at 35 and which also 
contains the Ibmier Care-of address and the new Care-of address of the mobile 

20 node 4. That packet is then sent at step 36 to the VPN gateway 2 and the routine 
terminates again at 31. 



OMjOoeSBEP spec EPC VBttal 



2SM«Gl>20a3 



-11 - 



Claims 

1. A method of communfcation between a private network (1) and a roaming 
mobile temninal (4), said private network (1) including a home agent (5) for said 
mobile terminal and a gateway (2, 3) through which said communication 
passes and which provides security protection for said private network (1), the 
protocols of said communication including security association bundles each 
including a security association between said mobile terminal (4) and said 
gateway (2, 3) for inbound communication and another security association for 
outbound communication, 

characterised in that. In response to a handover of communication causing an 
IP address (MN Co @) of said mobile temninal (4) to change to a new IP 
address (MN New Co @), said mobile terminal updates Hs Inbound security 
association from said gateway (2, 3) so that it can receive packets sent to it 
with said new IP address (MN New Co @) as destination, said mobile temiinal 
(4) sends a first signalling message with said home agent (5) as destination in 
a secure tunnel (20*) to said gateway (2. 3), said fiist signalling message 
indicating saki new IP address (MN New Co @) In secure fohn to said home 
agent (5), the inbound security association of said gateway (2, 3) from said 
mobile temninal (4) accepts said first signalling message without checking Its 
source address, said gateway (2, 3) forwards said first signalling message 
within sakI private networtc (1) to said home agent (5). said home agent (5) 
ched^ the validity of said first signalling message and, if it is valid, updates Its 
address data and sends a second signalling message to said gateway (2, 3) 
indicating said new address (MN New Co @), and said gateway (2, 3) updates 
its outbound security association with said mobile terminal (4) In response to 
the new address (MN New Co @) indicated. 

2. A method as claimed in daim 1, wherein communication between said mobile 
node (4) and sakI gateway (2, 3) is in accordance with an IPsec protocol 
specification. 
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3. A method as claimed in claim 2, wherein communication between said 
gateway (2, 3) and said mobile temiinal (4) is in accordance with an 
Encapsulating Security Payioad protocol used in tunnel mode. 

4. A method as claimed in any preceding claim, wherein a registration reply for 
said mobile node (4) is included in said second signalling message. 

6. A mobile terminal for use in communication by a method as claimed in any 
preceding claim, comprising means responsive to a handover of 
communication causing an IP address (MN Co @) of said mobile terminal to 
change to a new IP address (MN New Co @) for updating the inbound security 
association of said mobile temninal (4) from said gateway (2, 3) so that it can 
receive packets sent with said new IP address (MN New Co @) as destination 
and for sending a first signalling message with said home agent (5) as 
destination through a secure tunnel (20') to said gateway, said firet signalling 
message indicating said new IP address (MN New Co @) in secure form to 
said home agent (5). 

6. A mobile temninal for use in communication by a method as claimed in any 
preceding claim, comprising means responsive to a handover of 
communication causing an IP address (MN Co @) of said mobile terminal (4) 
to change to a new IP address (MN New Co @) for updating the outbound 
security association of said mobile terminal (4) to said gateway (2, 3) so that 
said mobile tennlnal (4) can send packets to said gateway (2. 3) with said new 
IP address (MN New Co @) as source address. 

7. A gateway for use in communication by a method as claimed in any preceding 
claim, comprising means responsive to said first signalling message received 
in a secure tunnel (20') from said mobile temninal with said home agent (5) as 
destination for causing said inbound security association at said gateway (2, 3) 
from said mobile terminal (4) to accept said first signalling message without 
checking its source address and for fonwarding said first signalling message to 
said home agent (5), and means responsive to said second signalling 
message indicating said new address (MN New Co @) for updating said 



CULOOBBBEP Spec EPC VBna 



2SMaich2003 



-13- 



outbound security association of said gateway (2, 3) with said mobile terminal 
(4) in response to the new address (iVIN New Co @) indicated. 

A home agent for use in communication by a method as claimed in any 
preceding claim, comprising means responsive to said first signalling message 
received from said gateway (2, 3) for sending said second signalling message 
to said gateway {2, 3) indicating said new address (MN New Co @) for said 
gateway to update its outbound security association with said mobile terminal 
(4). 
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Title: Communication between a private networlc and a roaming mobile 
terminal 

Abstract 

Communication between a private network (1) and a roaming mobile terminal 
(4), the private network (1) including a home agent (5) for the mobile terminal and 
a gateway (2, 3) through which the communication passes and which provides 
security protection for the private network (1). The protocols of the communication 
including security association bundles each include a security association between 
the mobile terminal (4) and the gateway (2, 3) for inbound communication and 
another security association for outbound communication, in response to a 
handover of communication causing an IP address (MN Co @) of the mobile 
terminal (4) to change to a new IP address {MN New Co @), the mobile terminal 
updates its inbound security association from the gateway (2, 3) so that it can 
receive packets sent to it with the new IP address {Mbi New Co @) as destination. 
It sends a first signalling message with the home agent (5) as destination in a 
secure tunnel (20') to the gateway (2, 3), indicating the new IP address (MN New 
Co @) in secure forni to the home agent (5). The inbound security association of 
the gateway (2. 3) from the mobile terminal (4) accepts the first signalling message 
without checking Its source address. The gateway (2, 3) fonA^ards the first 
signalling message within the private network (1) to the home agent (5), the home 
agent (5) checks the validity of the first signalling message and, if it is valid, 
updates its address data and sends a second signalling message to the gateway 
(2, 3) indicating the new address (MN New Co @). The gateway (2, 3) updates its 
outbound security association with the mobile terminal (4) in response to the new 
address (MN New Co @) indicated. 

Preferably, communication between the mobile node (4) and the gateway (2, 
3) is in accordance with IPsec and an Encapsulating Security Payload protocol is 
used in tunnel mode. Preferably, a registration reply for the mobile node (4) is 
included in the second signalling message. 
Figure 3 
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